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Abstract 

Projects  often  seek  to  deliver  new  or  improved  capabilities  within  complex,  poorly  defined 
and  changing  contexts.  The  application  of  MBSE  under  such  circumstances  can  be  problematic 
and  in  this  paper  we  discuss  these  issues,  and  suggest  approaches  for  their  mitigation. 

A  particular  system  solution  might  be  envisaged  as  a  combination  of  subsystems  connected 
through  a  common  architecture.  Systems  thinking  suggests  that  given  clear  requirements  and 
a  solution  concept,  one  can  move  forward  through  the  definition  of  subsystem  capabilities 
and  the  system  architecture  -  where  MBSE  is  particularly  useful.  However,  in  many 
applications  the  degree  of  turbulence  or  evolution  within  the  requirements  that  can  be 
expected  means  that  close  human  intervention  is  necessary  to  keep  the  solution  fit  for 
purpose.  Moreover,  this  human  intervention  must  be  based  on  significant  experience  and 
domain  knowledge  so  as  to  cope  with  the  many  Soft  System  issues  that  are  likely  to  be 
present.  At  University  College  London  (UCL)  Centre  for  Systems  Engineering  we  propose  five 
principles  that  we  believe  should  underpin  all  SE  development  projects.  In  this  work  we 
discuss  these  principles  and  their  application  to  MBSE  within  a  Soft  System  context. 

The  UCLse  principles  are: 

•  Principles  govern  process 

•  Seek  alternative  systems  perspectives 

•  Understand  the  enterprise  context 

•  Integrate  systems  engineering  and  project  management 

•  Invest  in  the  early  stages  of  projects 

Moreover,  we  will  also  look  at  how  encapsulation  can  be  used  to  protect  MBSE  sub-system 
developments  from  the  likely  changes  in  scope  and  direction  of  the  overall  development. 
Encapsulation,  while  fundamental  to  an  object  oriented  approach,  is  much  less  well 
developed  for  soft  systems  projects  except  where  it  manifests  as  a  pragmatic  approach  taken 
by  the  systems  engineer,  systems  engineering  manager  or  project  manager.  Through  an 
encapsulation  approach  one  can  create  a  system  from  the  inside  out,  i.e.  begin  sub-system 
development  before  the  final  structure  of  the  overall  system  is  fully  defined.  There  are 
parallels  with  a  system-of-system  approach  in  which  the  sub-systems  pre-exist  the  system.  Re¬ 
use  and  the  use  of  Commercial-Off-The-Shelf  (COTS)  and  Military-Off-The-Shelf  (MOTS)  sub¬ 
systems  are  natural  to  an  encapsulated  approach. 

An  important  element  of  such  an  approach  is  the  validation  of  the  chosen  system  architecture 
or  an  estimation  of  its  resilience.  This  can  be  undertaken  through  a  carefully  selected  (and 
weighted)  set  of  scenarios  -  the  consequences  of  each  being  used  to  define  the  interface 
margins  and  architectural  capacity  within  the  overall  system.  This  is  a  natural  extension  to  the 
concept  of  requirements  volatility  found  in  requirements  management  tools  etc. 
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Finally  we  will  look  at  the  bounds  of  MBSE,  where  is  it  not  a  practical  way  forward  and  where 
should  it  be  supplemented  and  augmented  by  a  Soft  Systems  front  end  and  concurrent 
activity?  For  instance  some  system  capability  uplifts  are  dominated  by  the  viewpoints  of 
existing  participants  and  are  often  in  situations  where  there  is  no  single  design  authority. 
While  MBSE  can  improve  their  toolset,  the  actual  system  level  changes  that  are  possible  may 
lend  themselves  more  to  change  management  than  MBSE. 
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But  what  is  MBSE? 

INCOSE  SE  Vision  2020  (INCOSE,  2007): 

“the  formalized  application  of  modelling  to  support  systems  requirements, 
design,  analysis,  verification  and  validation  activities  beginning  in  the 
conceptual  design  phase  and  continuing  throughout  development  and 
later  lifecycle  phases”. 

But  complex  system  development  without  modelling  is  unthinkable. 
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MBSE  for  soft  systems 

Let’s  avoid  a  debate  here  about  what  MBSE  is 
and  how  it  differs  from  ‘Conventional  SE’ 

Maybe  the  devil’s  in  the  ‘formal’  bit. 

•Instead  let’s  consider: 

-  Hard  and  Soft  Systems 

-  Application  of  UCL’s  principles  for  systems 
engineering 

-  Scenarios 

-  Encapsulation 


Hard  and  Soft  Systems 

Soft  system  element  (person  or  team) 
Hard  system  element 


Hard  system  element  with 
HCI 

Hard  System  requirements  come 
from  Soft  System  needs 


For  instance  a  capability  of  a  warship 
only  comes  about  when  you  add  the  crew 

Dealing  with  Soft  Systems  is  not  just  about 
HCI  or  Human  Factors  but  includes  such 
elements  as  buy-in,  legacy  thinking,  cultural 
change,  ... 


Hard  System 


Soft  System 
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UCL  Centre  for  Systems  Engineering 
Principles  of  Systems  Engineering 


Seek  alternative  Integrate  systems  engineering 

systems  perspectives  and  project  management 


Understand  the 
enterprise  context 


Invest  in  the  early 
stages  of  projects 

Principles  govern 
process 


Principle  1  -  Principles  govern  process 


When  adapting  a  generic  process 
to  a  particular  situation  the  individual 
must  first  understand  the  principles 
that  underpin  the  process. 

In  Soft  Systems  it  is  very  important  to 
understand  the  human  dimension. 
While  the  systems  development 
principles  will  be  common  to  Hard 
and  Soft,  the  application  will  not. 

For  instance  a  requirements  capture 
process  for  a  Hard  System  could  be 
very  different  to  that  of  a  Soft 
System.  Similarly  for  requirements 
validation  or  verification  etc. 


The  application  of  MBSE  to  Soft 
Systems  will  require  skilful 
application  by  the  system  engineer. 
Not  someone  with  a  tool  and  a 
handbook. 
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Principle  2  -  Seek  alternative 
systems  perspectives 


The  very  essence  of  Soft  Systems 
development  and  natural  to  Model  Based 
Structured  Analysis  and  Design 
Methodologies. 

MBSE  should  explore  a  range  of  systems 
perspectives,  viewpoints  or  abstractions 
to  enhance  understanding.  It  should  not 
be  confined  to  just  structure,  and 
behaviour  models. 

The  time  dimension  can  be  a  valuable 
source  of  Insight. 

-  Not  just  operational  sequences  and 
timelines  but  also  heritage  (which  informs 
buy-in)  and  foresight 

Recognise  the  importance  of  overlapping 
hierarchies 

-  Elements  that  are  parts  of  more  than  one 
system  require  appropriate  management. 


Principle  3  -  Understand  the  enterprise  context 


In  Soft  System  developments  the  separation 
between  the  system  and  its  environment  is 
often  fuzzy  while  in  MBSE  its  either 
technological  or  a  HCI/GUI. 

Taking  a  ‘Seven  Samurai’  approach  then  the 
Enterprise  is  just  an  other  system  (Soft)  within 
the  system  landscape. 

The  accommodation  of  Soft  System  often 
faces  many  diverse  constraints  from  the 
Super  System. 

In  Soft  Systems  lack  of  corporate  buy-in  and 
end  user  understanding  are  more  common 
causes  of  failure  than  technical  issues. 
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Principle  4  -  Integrate  Systems  Engineering  and 
Project  Management 


While  PM’s  tend  to  use  many 
simplistic  and  deterministic  tools 
(e.g.  Gantt  charts)  nevertheless  they 
are  dealing  with  an  essentially  Soft 
System  where  human  management 
is  necessary. 

Systems  Engineers  work  with 
relatively  deterministic  tools  and 
processes. 

Everyone  is  seeking  models  that  are 
understandable  and  useful 
The  efficacy  and  efficiency  of  such 
models  in  Soft  System  developments 
are  likely  to  be  quite  different  to  that 
of  Hard  Systems  developments. 


^UCL 

Principle  5  -  Invest  in  the  Resource 

Typical 

early  stages  of  projects 

ef  shifted  profile 

•  For  any  activity  in  a  project  there  will 

/  \  /  \ 

be  a  correct  time  to  undertake  it. 

\ 

-  Too  early  wastes  resources  while  too  late 

^  j  \  \ 

can  lead  to  downstream  adverse  impacts. 

•  The  optimum  ordering  of  activities 

should  be  identified,  resisting 

Time 

pressure  to  defer  work  until  later  for 

short-term  reasons. 

Soft  System 

front  end 

•  A  Soft  System  front  end  which 

creates  a  more  stable  requirement 

set  could  be  a  good  investment  for 

many  developments  which  are, 

eventually,  suitable  for  a  more  formal 

MBSE  approach. 
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Soft  System  Front  End 
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Agile? 

♦  Agile  accommodates  many  of  the  issues  typically  found  in  Soft 
Systems  (such  as  evolving  needs  and  stakeholder  requirements) 
through  an  iterative  and  rapid  lifecycle  that  includes  user  feedback. 

♦  However,  is  Agile  something  that  makes  up  for  the  absence  of  an 
effective  Soft  System  front  end? 

♦  Should  Agile  be  adapted  to  be  more  'left  shifted’,  in  which  much  of  the 
requirements  evolution  is  dealt  with  up  front. 
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Scenarios  Planning  /  Requirements  Validation 


In  Soft  System  project 
stakeholder  requirements  are 
likely  to  evolve  during  the 
development  of  the  systems 
and  after. 

The  baseline  requirements  set 
must  somehow  anticipate 
these  changes 
Through  the  use  of  scenario 
planning  these  requirements 
can  be  tested  for  robustness 

MBSE  projects  with  significant 
soft  system  aspects  should 
engage  in  scenario  planning 
as  part  of  requirements 
definition  and  validation. 


key  force  2 


Scenario  A 
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Encapsulation 

•  Soft  system  elements  may 
begin  as  very  well  defined 
structures 
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Encapsulation 

«  But  they  have  a  habit  of 
evolving  in  an  uncontrolled 
way 
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Encapsulation 


This  makes  for  downstream 
incompatibility 
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Encapsulation 

«  However  if  you  surround 
your  systems  elements 
within  a  standard 
interface 
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Encapsulation 

♦  Their  integration  is 
more  assured 

♦  They  are  more  easily 
tested 
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Encapsulation 

«  And  they  will  continue 
to  be  integrated  even 
as  they  evolve 

•  Scenario  Planning 
can  inform  the 
‘thickness’  of  the 
encapsulation. 
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Encapsulation 

•  After  all  a  systems 
architect  is  mainly 
interested  in  what’s 
inside  the  elements, 
only  what  the 
element  does. 
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Encapsulation 

«  Soft  Systems  Encapsulation  is  another  left-shifted  activity. 

•  It  includes: 

-  Robust  organisational  structures 

•  E.g.  robust  against  corporate  reorganisation 

-  Robust  cultures 

•  T aking  advantage  of  a  human  characteristic,  albeit  at  the  risk  of  downstream  inflexibility 

-  Robust  job  descriptions 

•  Titles  reflect  the  role,  e.g.  ‘Systems  Engineer’ 

-  Robust  tool  sets 

•  That  do  not  change  with  every  upgrade 
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Conclusions 

•  Hard  and  Soft  systems  are  related.  Often  the  Hard  Systems 
requirements  have  their  origins  in  a  Soft  System. 

‘  Soft  Systems  developments  use  models  too,  only  different  models. 

«  A  hybrid  lifecycle  could  be  imagined  with  a  Soft  System  front  end. 

•  If  we  are  to  imagine  a  hybrid  lifecycle  we  need  better  front  end  tools. 

•  E.g.: 

-  Rich  Picture  analysis  tools  that  create  influence  diagrams,  entity 
relationship  diagrams  etc. 

-  Scenario  Planning  tools  that  can  be  used  to  validate  Soft  Systems 
requirements 

•  Of  course  it  would  be  nice  to  know  what  MBSE  really  is. 
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